r? @madsmtm

rustbot has assigned @madsmtm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

The change itself seems simple, but I'd prefer to have someone from t-types review it.
r? types

If no-one there feels like they have the capacity, feel free to assign it back to me.

☔ The latest upstream changes (presumably #146348) made this pull request unmergeable. Please resolve the merge conflicts.

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

r? BoxyUwU

What's the reason for wanting to forbid such impls? Is it just because it's probably pointless to have pin_v2 on an Unpin type, or is there some soundness concern here?

It is for soundness concern.

For a type T annotated with #[pin_v2], it is allowed to project Pin<&mut T> to its field Pin<&mut U> safely (even if U: !Unpin). If T is allowed to impl Unpin manually, then &mut U could be obtained from &mut T that dereferenced by Pin<&mut T>, which breaks the safety contract of Pin<&mut U> for U: !Unpin.

If its soundness critical, I would add tests for impls of unpin for type aliases for adts marked pin_v2, e.g. impl Unpin for <Foo as Identity>::Assoc impl Unpin for Identity<Foo> (with lazy_type_alias feature enabled) and impl Unpin for TAIT (where TAIT is Foo).

rn your logic implicitly ignores all the cases where the self type is a non-adt 🤔 which I think is fine because we enforce that impls of Unpin are always for ADTs? But having tests is good :) It would probably also be good to explicitly match on the TyKind and in non Adt cases (which we expect to be unreachable) delay a bug maybe 🤔 that way you don't get unsoundness here if it goes wrong just an ICE

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.